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Graphical User Interface Features of a Browser in a (Hand-Held Wireless 

Communication Device 

This application claims the benefit of U.S. Provisional Patent Application no. 

5 60/216,549, filed on July 7, 2000, and U.S. Provisional Patent Application no. 

60/226,780, filed on August 21, 2000, both of which are entitled, "Graphical User 
Interface Features of a Browser in a Hand-Held Wireless Communication Device/' and 

J 8 4 both of which are incorporated herein by reference. 
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FIELD OF THE INVENTION 

ill 

The present invention pertains to wireless communication devices. More 
j£ particularly, the present invention relates to Graphical Useii Interface (GUI) features of a 
microbrowser in a hand-held wireless communication devite. 

15 BACKGROUND OF THE INVENTION 

For people and businesses requiring instant access tq information, the Internet 
and intranets have provided a vehicle for near real-time delivery of information from an 
enormous number of sources. For many of those same individuals, two-way mobile 
communication devices, such as cellular telephones, two-w^y pagers, Personal Digital 
20 Assistants (PDAs), Personal Information Managers (PIMs), pnd other handheld 

computing devices, have provided a way of communicating regardless of locality. In 
recent years, these two rapidly-advancing technologies have come together, such that 



the two-way mobile communication device has become on^ of many entry points into 
the Internet and intranets. 

Devices used to access the Internet (or Intranets) generally have certain features 
in common, whether they sit on a desktop or are held in th£ palm of the hand. One 
5 feature such devices may have in common is that they maybe used to display 

! 

hypermedia content, such as web pages. To do so, network servers and network 
personal computers (PCs) normally use standard web protocols and mark-up 
Lf! languages, such as Hypertext Transport Protocol (HTTP) ar|d Hypertext Markup 
W Language (HTML), respectively. Mobile devices generally Use wireless protocols, such 
1 Jl as Wireless Access Protocol (WAP) or Handheld Device Transport protocol (HDTP), 
□ and wireless markup languages, such as Wireless Markup language (WML) and 
S3 Handheld Device Markup Language (HDML), to accomplish the same task. 

One problem with using many conventional mobile devices to access the Internet 
is the lack of user-friendliness of their user interfaces. Because these devices are 

1 5 designed to be mobile, they normally have very small displays, compact keypads and, 
commonly, only a limited provisions for pointer /cursor movement For example, such 
devices commonly have only two directional arrow keys (e-g v Up and Down arrow 
keys) to control pointer or cursor movement and highlighting. Such devices are 
referred to herein as "two-arrow" devices. This pair of keyk can specify cursor or 

20 pointer movement only along one axis at a time. In contrast conventional PCs 
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commonly use pointing devices that can specify pointer or cursor movement 
simultaneously and directly along two perpendicular axes (jLe., horizontally and 
vertically), such as a mouse, trackball, touchpad, or the like. Such pointing devices are 
referred to herein as "direct" pointing devices. These restrictions exist on mobile 
devices because the mobile devices are designed to be relatively inexpensive and small 
so as to fit into the palm of the hand. 



3 



Communication device that 



SUMMARY OF THE INVENTION 

The present invention includes a hand-held wireless ( 
includes a microbrowser with improved graphical user intelrf ace features, as well as a 

method and other apparatus for providing such features, ijhe hand-held wireless 

i 

5 communication device may lack a direct pointing device. ! 

In one aspect of the invention, the microbrowser displays a dual 
ii browser/application menu on a display in response to a us^r input. The dual 
W browser/application menu includes multiple icons arrange^ in a row, each of which 
"^i represents a different browser-specific function. The dual browser /application menu 
IjO also includes multiple substantially text-based items arranged in a list in proximity to, 
*« but oriented differently from, the icons, wherein each of th^ substantially text-based 
^ items represents a different application-specific function. 

In another aspect of the invention, the microbrowseij persistently displays an 
icon in a predetermined part of each of multiple display sojeens of hyperlinked content. 

1 5 The icon represents a pop-up browser menu that contains iKultiple items representing 

i 

browser-specific features. The microbrowser responds to liser selection of a 
predetermined selectable item in any of the display screens by providing a user- 
perceivable indication that the pop-up browser menu is currently selectable. The 
microbrowser responds to a selection input when the pop-ip browser menu is currently 
20 selectable by displaying the pop-up browser menu. 
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In another aspect of the invention, the microbrowseri displays multiple user- 
editable controls on the display and places one of the controls in an editable mode, to 
enable editing of the control by a user. The microbrowser then receives a user input for 
editing the control. In response to a single user input indicating that editing of the 
5 control is complete, the microbrowser automatically places p. next one of the controls in 

an editable mode without requiring additional user input. 
m In another aspect of the invention, in a hand-held wifeless communication device 

f y which lacks a direct pointing device, the microbrowser displays two or more softkeys 
*i on the display concurrently with displaying any of the user^editable controls. A first 
1 CT softkey is operable to place any of the controls in an editing! mode. A second softkey is 
operable to display a menu when any of the controls is in a.t\ editing mode. The content 
of the menu varies according to which of the controls is currently in an editing mode. 
In a variation of this aspect of the invention, one of the controls may be edited in each of 
a text input mode, a numerical input mode, and a symbol irtput mode. In that variation, 
1 5 the menu associated with the second softkey includes multiple items, which are 
selectable to allow a user to switch between the aforementioned editing modes. 

In another aspect of the invention, in a hand-held witeless communication device 

which lacks a direct pointing device, the microbrowser displays a table having multiple 

i 

rows, each of which has multiple user-editable cells. The microbrowser sequentially 
20 enables the rows for selection in response to successive user! inputs from the pointing 
device. The microbrowser further selects one of the rows which is enabled for selection 
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in response to a user input. When one of the rows has been selected, the microbrowser 
sequentially enables cells within the selected row for selectibn, in response to successive 
user inputs at the pointing device. 

In another aspect of the invention, in a hand-held wifeless communication device 
which lacks a direct pointing device, the microbrowser displays a mark-up language 
based screen on the display. The mark-up language based ^creen includes a body and a 
static area located adjacent to the body. The body is scrollable in response to user 
inputs from the pointing device. The static area includes a control operable in response 
to user inputs, but is non-scrollable, so as to remain visible when the body is scrolled. 
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BRIEF DESCRIPTION OF THE DRAWINGS : 

The present invention is illustrated by way of example and not limitation in the 
figures of the accompanying drawings, in which like references indicate similar 
elements and in which: 

5 Figure 1 illustrates a network environment in which ja mobile communication 

device may be used; 

CO Figure 2 is a schematic view of a two-way mobile coiWnunications device that 

: ; : may be used to access the Internet; 

« Figure 3 is a block diagram of the principle componehts of the two-way mobile 

10- communications device; 

u Figures 4A through 4F are a sequence of screens generated by the browser of the 

mobile device, showing a combined browser and application menu; 

Figures 5 A through 5F are a sequence of screens generated by the browser of the 

! 

mobile device, showing a Browser Menu that can be accessed from the title bar; 

1 5 Figures 6A through 6D show a series of screens for aiji example of the operation 

of the auto-jump feature; 

Figures 7 A through 7E show a series of screens for a Second example of the 
operation of the Auto-Jump feature; 
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Figures 8A through 80 show a series of screens for a^i example of how the 

i 

control context sensitive menu feature operates; 

Figures 9A through 9E show a series of screens for aij\ example that demonstrate 
how this table navigation feature works; I 

5 Figures 10A through 10K show a series of screens foi an example of the 

0 operation of the calendar navigation with smart selection o^ dates; and 

I* Figures 11A and 11B show a pair of screens for an example of how the non- 

1 ] | scrollable header feature operates; 

I J Figures 12A through 12D show a sequence of screens illustrating an example of 

1 0? the operation of the Growing Text Box feature; 
J!H Figures 13A through 13U show a sequence of screens illustrating an example of 

jU the operation of the Auto-Fill feature; \ 

Figures 14 A through 141 show a symbol entry feature of the browser; and 
Figures 15A through 15D show a dual feedback feature for improving usability 
15 of sof tkey activated controls. 
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DETAILED DESCRIPTION 

A method and apparatus for providing a microbrowser with a Graphical User 

Interface (GUI) in a hand-held, wireless, mobile communication device are described. 

i 
i 

Note that in this description, references to "one embodiment" or "an embodiment" 
5 mean that the feature being referred to is included in at lea^t one embodiment of the 

present invention. Further, separate references to "one embodiment" in this description 

j 

% J do not necessarily refer to the same embodiment; however,! neither are such 
ry embodiments mutually exclusive, unless so stated and except as will be readily 
W apparent to those skilled in the art. 

TO 1 A microbrowser in a hand-held mobile communications device can be designed 

^ to provide a GUI that is more user-friendly than those of prior mobile communications 
f y devices, as described below. As used herein, "hand-held" ijieans designed to be held in 
f ~ the palm of the hand. A "browser" is a component that allcjws a user to access a web of 

hyperlinked content, such as the World Wide Web on the Internet. A " microbrowser" 

i 

15 is a type of browser that is designed for use in a hand-held device. 

i 

The GUI features described herein address problemsj associated with a mobile 

communications device that has relatively few input keys, ^nd in particular, restrictive 

i 

functionality for cursor movement and pointing. As described in greater detail below, 
the GUI features may include: a combined browser-application menu that includes a 
20 dismiss bar and browser options represented by horizontally displayed icons; a 

separate browser menu accessible from a title bar of a displayed screen; an auto-jump 



feature that automatically highlights the next actionable control when a control is done 



being edited; a control-sensitive softkey menu that changes 
currently in use; table navigation that allows more efficient 



according to the control 
navigation through table or 



calendar entries using two arrow keys; a non-scrollable header with actionable controls, 
5 to allow the use of frames in conjunction with markup content; an improved text input 

feature; an improved symbol entry feature; and improved (iiual) feedback when using 
3 soft key controls. 

5 Figure 1 shows a network environment in which a rrtobile communication device 

3 (or simply "mobile device") can be used. Mobile device 106 may be of any of the types 
of mobile devices mentioned above, such as a wireless telephone, for example. To 

as" 

^ facilitate explanation, the example of a wireless telephone i^ used at various points in 
3 the following description. Mobile device 100 is configured j;o retrieve remotely stored 
hypermedia information, such as WML documents, HTML jdocuments, Compact HTML 
(cHTML) documents, Extensible Markup Language (XML) jdocuments, or HDML 
documents, from one or more network server device, showh as network servers 116 and 
120. Network Servers 116 and 120 may be, for example, conventional personal 
computers (PCs) or computer workstations. Mobile device 100 has a display 102 and a 
keypad 103 o i 

Mobile device 100 also includes and executes a micrcjbrowser (not shown), which 
is software that allows the user of mobile device 100 to access the Internet, including 
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1 f 

! 

browsing the World Wide Web or any other "web" of hypermedia content. One 

j 

example of a microbrowser that may be used for this purpose is the UP.Browser 
microbrowser from Openwave Systems Inc. of Redwood Cjty, California. The 
microbrowser may be stored in memory within the mobile device 100. The 

5 microbrowser generates a GUI via display 102 to enable th0 user of the mobile device 
100 to access and retrieve hypermedia information from network servers 116 and 120. 
Various features of the GUI, which make the microbrowser more user-friendly, are 

fy described below. 

^ The communication path between mobile device lOOj and network servers 116 

1ft and 120 includes a wireless communication network ("airnet") 104, a proxy server 108, 
O and a land-based network ("landnet") 112. Airnet 104 is a Network such as a Cellular 
Digital Packet Data (CDPD) network, a Global System for Mobile (GSM) network, a 
Code Division Multiple Access (CDMA) network, or a Timi Division Multiple Access 
Network (TDMA) network. The communications protocol^ used by airnet 104 may 
1 5 include, for example, WAP and/or HDTP. Landnet 112 is 4 land-based network that 
may be or include the Internet, an intranet, or a data network of any private network, 
such as a Local Area Network (LAN). The communication protocol supporting landnet 
112 may be, for example, Transmission Control Protocol (TCP/IP), HTTP, or Secure 
HTTP (sHTTP). 
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Proxy server device 108 acts a bridge between airnetj 104 and landnet 112. Proxy 
server device 108 may be, for example, a conventional computer workstation or PC. 
Although shown as a physically separate device, proxy serfer 108 may be implemented 
in a network server device (e.g. network servers 116 or 120)! with hardware and 
5 software well known in the art providing the connection between airnet 104 and 
landnet 112. 

r% Figure 2 is a schematic view of the mobile device 100, according to one 

l : fi embodiment. As shown, mobile device 100 includes a display 102 and a keypad 103. 
5 ^ Display 102 may display hypermedia information, such as Information 208, and, 
13^ depending on the current mode of the device, one or more ^oftkey labels, such as 
y softkey label 212. Function keys 216 and 220 can be used to! activate softkeys 
12 represented by the softkey labels (when enabled). 

It is useful to now define what is meant by a "softke^". A softkey is a user- 
operable feature that is analogous to a physical (i.e., purely Jnardware-based) key or 

1 5 button, but which is formed by a combination of a physical key (e.g., either of keys 220 

i 

and 216 in Figure 2) and a softkey label displayed on the diiplay 102. Because not all 
features can be easily mapped to specific keys on small, wireless devices, the use of 
softkeys has become commonplace for manipulating items <bn the screen and initiating 
functions. Such devices typically have no direct input mechanisms (e.g., pen-based 
20 input or mouse input (such as on a PDA or PC respectively). To compensate, softkey 
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functions are indicated by labels displayed directly above the physical (hardware) keys 
that operate the softkey functions. To facilitate description; softkey labels are 

sometimes referred to herein simply as "softkeys". It will t^e understood, however, that 

i 

"pressing" or otherwise activating a softkey is accomplished by pressing the physical 
5 key which corresponds to the softkey function, i.e., is locatdd below the corresponding 
softkey label. 

0 Referring still to Figure 2, keypad 103 includes alph^numerical keys 230 (such as 

1 for dialing a telephone numbers and entering links), function keys 216 and 220, Up 

* arrow key 221A, and Down arrow key 221B. Arrow keys ^21A and 221B are used to 
1 navigate through information displayed on display 208, such as to move a selection 
3 indicator (e.g., highlighting), cursor, pointer, or other indicator, or to scroll the display. 

The hypermedia information 208 shown in Figure 2 includes a list of selectable 
identifiers (e.g. "UP Home") having corresponding Uniforih Resource Identifiers 
(URIs). Hypermedia information 208 may be, for example, ja WML file, or "deck", 
including one or more WML cards. In certain modes of operation, activating function 
key 220 while a displayed item is selected (e.g., highlighted} causes mobile device 100 to 
retrieve and display a WML card associated with a URL of that item. In addition, using 
the alphanumerical keys 230, the user may enter a URL matmally to access hypermedia 
content. To facilitate this operation, the microbrowser may 1 provide several different 
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input modes, such as a number input mode, an alphabetic input mode, a symbol input 
mode, and a URL input mode. 

Figure 3 is a block diagram showing the principle components of mobile device 

! 

100, according to one embodiment. The mobile device 100 includes a processor 301, 

5 which may be or may include any of: a general- or special-pfurpose programmable 

I 

microprocessor, Digital Signal Processor (DSP), Applicatiori Specific Integrated Circuit 
f 5 (ASIC), Programmable Logic Array (PL A), Field Programmable Gate Array (FPGA), 
m etc., or a combination thereof. Mobile device 100 includes a Wireless Control Protocol 
H (WCP) interface 313 that couples to a carrier network via aiinet 104 to receive incoming 

and outgoing signals. Device identifier (ID) storage 316 stotes and supplies to WCP 
£3 interface 313 a device Id which identifies mobile device 100 jto outside entities (e.g. 
H proxy server 108). The device ID is a specific code that is associated with mobile device 

100 and directly corresponds to the device ID in the user actount typically provided in 

j 

an associated proxy server device, such as proxy server 1081 

15 In addition, mobile device 100 includes memory 304 that stores data and/ or 

software for performing many of the processing tasks performed by mobile device 100, 
including the microbrowser (or "browser") 320, when executed by processor 301. These 
tasks include: establishing a communication session with a j^roxy server device via 
wireless link 332 and airnet 104; receiving user inputs from jkeypad 103; requesting and 

! 

! 

20 receiving data from the carrier network; and displaying information on the display 102. 
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Hence, memory 304 may represent one or more physical memory devices, which may 

include any type of Random Access Memory (RAM), Read-Only Memory (ROM) 

i 

(which may be programmable), flash memory, non-volatile! mass storage device, or a 

combination of such memory devices. Memory 304 is also jzoupled to WCP interface 

i 

5 313 for the establishment of a communication session and tKe requesting and receiving 
of data. 

!^ The mobile device 100 also includes voice circuitry 3fL8 for inputting and 

|i outputting audio during a telephonic communication between the user of mobile device 
S3 100 and a remote party. Voice circuitry 318 may include, for example, sound 
TO, transducers, analog-to-digital (A/D) and digital-to-analog (Jd/A) converters, filters, etc., 
n such as are well-known in the art. An encoder /decoder 3l6 is coupled between the 
C3 processor 301 and the voice circuitry 318 for encoding and decoding audio signals. 

What follows is a description of various features of the GUI generated by the 

i 

microbrowser (hereinafter "browser") 320 of the mobile device 100, any or all of which 
1 5 may be implemented in a given embodiment, to make the rjiobile device 100 more user- 
friendly. It will be readily apparent to those skilled in the a^t how to implement these 

GUI features in program code, from the following description of the user-perceivable 

i 

characteristics of these features. A browser that incorporates these features may be 
written in a conventional programming language that is currently used to implement 
20 microbrowsers for mobile devices. The various features described below do not all 
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have to be implemented in a given device, although doing so may result in the best 

! 

performance from an end user's perspective. ! 

Note that as an alternative to the browser 320 generating the following GUI 
features, these features can instead be provided by a remote device (e.g. proxy server 
5 108 or servers 116 or 120), such that the mobile device only receives and displays these 
features to the user. 

_W I. Dual Browser-Application Menu 

*! j Applications on mobile devices often require the accessibility of both application- 

15 specific features and browser-specific features. It is desirable to provide both types of 

O features in a single menu that is always accessible. This approach provides the user 

If, with a single menu or screen for every action, making the application more efficient for 

|x the user. However, several usability issues arise in attempting to implement both an 
application menu and a browser menu. Separate menus m$y require two dedicated 

1 5 keys, one for each menu. Most mobile devices cannot aff or ji to make these keys 

i 

available. Consequently, one or both menus may be hiddei^ under non-intuitive keys 
on the device, or both menus may be combined and assigned to a single menu that 
confuses the user. A combined menu with both browser add application options can be 
confusing, because the user may not be able to readily distinguish between application 
20 menu items and browser menu items. For example, if the menu provides the option, 
"Exit", it may not be clear whether the option will result in Exiting the browser or just 
the current application. 

16 



In addition, users are sometimes confused about ho^ to dismiss (exit) menus 
using the limited number of keys on the mobile device. It rhay be easy to bring up the 
menu, but not always clear how to dismiss it without making a selection. Arrow keys 
usually highlight items only, and a Select or Enter key seledts the item the user 
5 highlighted. If the user wants to leave the menu without selecting anything, he may be 

confused about how to do this. Merely placing "Cancel" onj every menu is not a good 
3 solution, because the user tends to think he can use the meiiu to "Cancel" an application 
FLJ operation, not the menu. Similar confusion may arise for other terms such as "Dismiss" 
1% (i.e., whether it dismisses the application or the menu), "Delete", etc. 
1 IT Consequently, the GUI of a mobile device, such as miobile device 100, may 

*S provide a combined browser-application menu, as described below, to allow one menu 
Jjf to meet both browser-specific and application-specific need^. The combined application 
menu and browser menu is particularly suited for devices that have no direct pointing 
device (e.g., a mouse), such as those mobile devices having Only two-way arrow cursor 
1 5 keys (e.g., Up and Down arrow keys 221 A and 221B) and ohe selection key (e.g., a 
softkey). As used herein, the term "direct" pointing device jmeans a pointing device 
that can specify position coordinates and/ or can move a pointer, cursor, selection 
indicator or the like simultaneously along at least two perpendicular axes. The menu 
itself can be accessed from either a primary activation key dr, as in the examples 
20 provided herein, a secondary softkey. 
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Figures 4A through 4F show a sequence of screens generated by the browser of 
the mobile device, showing a combined browser-applicatio^ menu. As shown in 
Figures 4B through 4F, the combined menu 401 includes browser options in a Browser 
Bar 402, which includes a set of icons representing browser functions in a row across the 
top of the menu. These icons are clearly differentiated from the application options, 
which are listed as text in a vertical list below the Browser ^ar 402. The icons of the 
Browser Bar 402 consume little space so as to avoid the browser features dominating the 
menu. The menu 401 also includes a Dismiss Bar 403 that tlfie user can select to dismiss 
the menu 401. The Dismiss Bar 403 provides improved mejiu usability for limited 
keyboard devices. The menu 401 also includes application menu options 404 (the 
options below the Dismiss Bar) associated with the current application. Note that this 
type of menu look and feel can also be used for functions ot)ier than just browser and 
application menu items. 

Table 1 describes an example of the operation of the (tombined browser- 
application menu in conjunction with Figures 4A through 4^. 

Table 1. Browser- Application Mefiu 



Action 


Result / Expla 


nation 


Start — Figure 4A. 

Begin in the "Calendar Pick" screen, as 
shown. 


The left (prima 
for the applicai 
highlighted sp] 
(secondary) so] 
application-de 
404 and 405 cai 
function keys 2 
(Figure 2) on n 


ry) softkey 404 is available 
ion (i.e. to change the 
n control), and the right 
: tkey 405 is available for an 
pendent menu. Softkeys 
i be activated using 
20 and 216, respectively 
Lobile device 100. 


Softkey 2 Pressed. 


Figure 4B. 
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The user presses the right softkey 405 to 
bring up the combined browser- 
application menu 401. 


The left softke 
it is no longer 
menu is up. T 
and Down an 
select an item. 

The right softi 
since the Disrr 
Dismiss Bar 4C 
to the user tha 
with no harm. 


y 404 is now disabled, since 
available while the softkey 
he user can only scroll Up 
d use the ricrhf" soffkev 40^ to 

;ey is labeled "Dismiss", 
iss Bar is selected. The 
>3 is a visual way to indicate 
t they can dismiss a menu 


Down Pressed. 

The user presses the down arrow key 221B 
(Figure 2) to highlight the next menu item 
down the list. 


Figure 4C. 
Scrolling dowi 
menus. Theu 
down to highl 
user can at an) 
405 to select th 

The softkey lal 
menu item is s 

The menu iten 
application de 
visually distin 
below the Disr 


i is how the user highlights 
ser can continue to scroll 
ight other menu items. The 
r time press the right softkey 
at item and cause its action. 

;>el changes to "Select" once a 
elected. 

is on the bntfnm are tVip 

pendent menus. They are 
guishable by their text labels 
niss Bar 403. 


Up Pressed. 

The user presses the up arrow key 221A to 
highlight the previous menu item up, 
which is the Dismiss Bar 403. 


Figure 4D. 
The user can s< 
menu in its pre 
menu without 


:roll back up to put the 
ivious state and dismiss the 
an action. 


Up Pressed. 

The user presses the up arrow key 221A to 
highlight the previous menu item up, 
which is the first icon in the Browser icon 
bar 402. 


Figure 4E. 
The Browser B 
Bar 403. Italic 
browser menu 
screen. Since E 
common on al 
with icons abo 
visually separa 
menu. 

The right softk 
there is a meni 


ar 402 is above the Dismiss 
ws the user to select 
options that occur for any 
Jrowser menu items are 
screens, they are displayed 
ve the Dismiss Bar 403 to 
/te them from the rest of the 

ey again says "Select", since 
i item available for select. 
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Up Pressed. 

The user presses the up arrow key 221 A to 
highlight the previous menu item up, 
which is the next icon to the right in the 
Browser icon bar 



Figure 4F. ; 

The user can continue to press the Up 
arrow key to go right across the Browser 
Bar 402. Scrolling Down will move the 
cursor left across the bar and back down 
the list of itemp, starting with the Dismiss 
Bar. The icons, in the Browser Bar 402 will 
scroll left and right if there are more 
icons /options than can be displayed 
within menu 401 at one time. 



Hence, this menu feature improves browser usability while packing more 
Co features into a small screen in a device with a limited keyboard, i.e., one without a 
W direct pointing device such as a mouse, and without adding a dedicated key. The 
Jf§ operation of the menu is also easily discoverable by the uset. The user sees the Dismiss 
p Bar 403 and the Dismiss softkey at the bottom of the display and intuitively knows it is 
O a menu dismiss option. Further, it is natural for the user to Scroll up to the browser- 
q oriented icons or down to the application-oriented text, and it is easy for the user to 

recall how the menu operates. The use of icons to represent browser options and text to 
1 0 represent application options allows the user to easily distinguish between the two 

types of options. 

II. Pop-Up Browser Menu ! 

With a browser executing on a wireless device, often |not all desired functions can 
15 be easily mapped to specific keys on the device. The browser of mobile device 100 may 
provide a menu of browser features, a Browser Menu, that i^ made available from a 
single key. The Browser Menu is a collection of browser features that generally are 
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used when the user is browsing any web site. For example; the Browser Menu includes 
features such as bookmarking the current page; jumping to j the Home page; viewing the 

Uniform Resource Locator (URL) of the page the user is visiting; or exiting the browser 

i 

to make a phone call. Generally, all of these features are us^d wherever the user is 
5 browsing, and a mobile device keypad either does not havd enough keys to dedicate to 
each feature, or it would be non-intuitive to assign these functions to the existing keys. 
3 To solve this problem, the Browser Menu is typically activated by one keystroke 

jj* or a set of keystrokes. Consequently, only one key is needed on the device to access all 
| of these features. However, some Browser Menu features a^e rarely-needed features 

that nevertheless must exist. For example, the user may choose to "Bookmark" any site 
z they browse to, but the user will only use this feature one tiine for each site he wants to 
remember. Thus, the "Bookmark" feature should be made Available for all cards, but the 
user will rarely need it. This is the nature of virtually all of the usual Browser Menu 
commands. Features that are used more often need not appear in the Browser Menu, 
because they require dedicated keys (such as Up arrow, Down arrow, "Select," and 

"Back"). "Back," for example is usually assigned to the "CL^," "END," or a dedicated 

i 

softkey and does not require a menu item in the Browser M^nu. 

i 

One problem that has evolved, therefore, is related tcj how the Browser Menu is 

i 

assigned to a key on the mobile device. Most mobile telephones, for example, have too 

i 

few keys available to accommodate a dedicated key to the browser Menu. Phones with 
extra keys are rare, as extra keys make the phone bulkier, arid thus, less popular. 
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Hence, it is difficult to find a key to assign to the Browser Ivjtenu, and since it is not used 
often, there is little justification for assigning it to a prominent key. 

Combining an often-used feature with the Browser Menu causes the user to have 
to go through multiple keystrokes to select the popular itenji. For example, if "Back" is 

placed on the Browser Menu so that a key can be used for fcjoth "Back" and the Browser 

i 

Menu, the user must first hit the key to bring up the Browser Menu and then hit the 
Select key to select the "Back" function. This approach mak^s the very often used "Back" 
function require two keystrokes, causing tedium for the us^r. 

Many phones hide the Browser Menu under a "longjpress" of a key (e.g., long- 
press of the "#" key). There are at least two problems with tjhis approach. First, on 
phones where it is hidden on a long-press of an already rarily-used key (e.g., "*" or "#"), 
the user may never discover this menu and therefore may b|e penalized by not having 

i 

access to valuable features like "Home," "Exit," or "Bookmarks." On devices where the 
Browser Menu is under a long press of a more frequently u^ed key, such as a long press 
of a softkey, the user may accidentally stumble into the Browser Menu when the key is 
unintentionally pressed too long. In this situation, the user tends to become confused 
and not understand that the Browser Menu is a separate m^nu and not a menu 
provided by the web site he is visiting. 

Some browsers make a soft key available for this mehu. In this implementation, 
they commonly use the word "Options" to lead to this mentj. To accommodate for the 
need for more programmable softkeys, such devices have th[e programmable softkeys in 
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the Browser Menu (under "Options") along with the Browser Menu command. The 
problem with this approach is that most of the time, the us^r does not need the Browser 
Menu, but the programmable softkeys, which are much mc^re relevant and used more 
often, are now an extra keystroke away and are not visibly labeled on the web page on 
5 which they operate. For example, when viewing an email rhessage, the options to 
Delete and Reply may be in the Options menu when they c6uld be available on a 
~: softkey label where the user wants it while he is reading entail. Good usability design 
jj would dictate that this key not be dedicated to such an underused feature. 
J Another proposed solution has been to put Browser Menu options on a scrolling 

1 softkey. This approach allows the user to scroll to the right land select additional 

softkeys that are not visible initially. This is a solution whicjh works well on phones that 
y have four-way arrow keys. Scrolling softkeys does not wor^ with most mobile devices, 
however, as most mobile devices only support up and dowh scrolling, which must be 
used for menu selection instead of softkey selection. 

The foregoing problems can be solved by a three-par^; approach. First, a new 
visualization for the Browser Menu is used, such that the Br|owser Menu is a pop-up 
menu, rather than rendered to appear like another card or \yeb site. This approach 
gives a visual indication to the user that the menu is different. Second, by displaying 
the Browser Menu access point in the title bar of the web site, the Browser Menu can be 
accessed from any card. The first time the user scrolls up oh a card, the Browser Menu 
is highlighted. Third, a visual indicator is added in the Titte Bar, so that the user can see 
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the that there is something up there that he can try to interact with. The resulting 
Browser Menu is accessible from any card of any web site Without requiring it to be 
mapped to a dedicated key. In a given device, this feature may be complementary to 
that of the combined browser-application menu described above. 

Underlying this approach is the realization that the browser Menu features do 
not require immediate accessibility from any position on a j:ard. Thus, if the user scrolls 
down 10 times, they will have to scroll back up 11 times to ^elect the Browser Menu. 
This is acceptable, since the Browser Menu commands are ijarely needed for a card. 
However, on arrival to any card, the Browser Menu is only ja few keystrokes away 
(usually an Up scroll followed by a Select of a softkey or action key). 

Figures 5 A through 5F show a series of screens for ah example that demonstrates 

! 

how the Browser Menu operates, as described in Table 2. lift this example a user 
traverses from a Home Page or startup card, into an application (Email is this example), 
and then use the Browser Menu to return to Home. A T" icon (e.g., the logo of 
Phone.com, a predecessor of Openwave Systems) is used injthe title bar in these 
examples to denote the Browser Menu. 



Table 2. Pop-Up Browser Meni| 



Action 


Result / Expla 


nation 


Start. 

Begin in the Home Page of a browser, as 
shown in Figure 5A, where the user can 
select to access any of multiple web sites. 


The first menu 
highlighted. T 
key (which ma 
softkey) to sek 
can use the Up 
221 A and 221B 
menu item for 


item, "Email/' is 
he user can use the "Select" 
y be Enter key 220 or a 
ct any menu item. The user 
and Down arrow keys 
to highlight a different 
selection. 
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Notice the T" 
This icon repr 
For this exam] 
until after pro 
application. 


icon 501 in the title bar 501. 
esents the browser menu. 
Die, it will not be selected 
ceeding into the Email 


Select Pressed. 

The Select key is pressed on the previous 
screen to go to the Email web site. 


Figure 5B. 

The title-bar 502 is now labeled "Email;* 
but the "P M icojn 501 remains. This 
indicates to th^ user that the Browser 
Menu is always available on any web site. 


Up Pressed. 

The user presses the Up arrow key 221 A to 
highlight the "P" icon 501 representing the 
Browser Menu. 


Figure 5C. 
ine l iconot 
black) to show 
highlighted ar 

Note: TheBro 
automatically 
501 is selected, 
meant to scrol 
item on the sci 
key 221B need 

cffnl 1 i"n O" V^ar'V 

OK-L U11J.1 Lii L/ClV-iS. 

though menu i 
"Select" the brc 
Key to bring u 

Variations can 
the browser m 
up, but where 
keystroke will 


31 is now inverted (white on 
that it is the currently 
ea of the screen. 

wser Menu does not 
pop up when the "P M icon 
since the user may have 
. to the top control or menu 
een, and the down arrow 
s to be available for 
uuwii ^ciiiu. nut rur scrolling 
terns). The user must 
)wser menu with the Select 
o the menu. 

be implemented, in which 
enu does automatically pop 
an additional up-arrow 
dismiss the menu. 


Select Pressed. 

The user presses the Select key to pop up 
the Browser Menu. 


Figure 5D. 
The Browser & 
first item in the 
automatically 1 
accessed quick 
item in the mei 
dismissing the 

The user can n< 
highlight the n 


lenu is now displayed. The 
i Browser Menu is 
lighlighted to allow it to be 
ly. In this example, the first 
iu is the Dismiss Bar for 
browser menu. 

3w scroll up or down to 
lenu item he wishes to 
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choose. 




Down Pressed. 

The user presses the Down arrow key 221B 
one time to highlight "Home." 


Figure 5E. 
The "Home" it 
selection. The 
to cause the bi 
Page. 


em is now highlighted for 
user can now select Home 
'owser to go to the Home 


Select Pressed. 

The user presses the Select key to select 
"Home." 


Figure 5F. 

The browser returns to the Home Page, 
with the first i^em, "Email", highlighted. 



Hence, a Browser Menu is added to the browser's features without requiring any 
dedicated keys or new key assignments. The existing Up atrow key 221 A, Down arrow 
key 221 B, and Select key 220 are sufficient to use this featur^. This feature is easily 
discoverable by the user over normal usage of the browser.: The Browser Menu is easily 
distinguishable from other menus. The user will discover it either by accident or by 
noticing, from the icon in the title bar, that there is something above the displayed 
content that may be selectable. The user may find this feature by accident the first time 
he scrolls up to highlight the first item in a card and he accidentally scrolls one time too 
many, causing the "P" icon 501 in the title bar 502 to becom^ highlighted. The 
highlighting of the "P" icon 501 in the title bar 502 is the visiial feedback that makes this 
discoverable. In addition, this feature is easy for a user to remember. As soon as the 
user discovers the Browser Menu in the title-bar 502, he will immediately and 
continually associate the "P" icon 501 in the title-bar 502 as k place to go for extra 
features. Also, the "P" icon 501 is unobtrusive and does not take away a valuable key 
from the user that could be used for more important features. 
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III. Auto-Jump 

Browsers on most mobile devices must be operated i|n a limited navigational 
environment due to the fact that these devices have so few keys and no "smart" input 
mechanism such as a mouse or pen-input. One area of concern is any operation that 
5 requires a greater number of keystrokes than what seems reasonable to the user. One 

particular area where the user may feel that too many keystrokes are required is when 

i 

! 

M the user wants to edit a set of fields in a form of fields. To c|o this the user typically 

IT\ must, for every field, put the field into edit mode, make thej desired edits, take the field 

in I 

ly out of edit mode, and then scroll to the next field. In the caie of selecting a radio button 

in a group of radio buttons, this may mean that the user has to scroll down past all the 
*5 remaining radio buttons in the group that he did not select J Therefore, a quicker way to 
m accomplish this goal is needed. 

H ; A solution to this problem is now described and is referred to herein as "auto- 

jump". The auto-jump feature operates as follows: 1) Upo|i entering any screen, the 
15 up/ down arrow keys 221 A and 221B are used for scrolling ^nd highlighting of controls 
initially. 2) After a user takes a control out of "Edit" mode ([e.g., completing an edit in a 
text edit control), or if the user selects a simple control like a radio button or checkbox, 

then the next control is automatically highlighted. (A "contjrol" is a user interface 

j 

feature with which a user may interact to cause a function o|r enter input.) If the user 
20 selects a radio button or other similar grouping of controls tlhat the browser can detect, 
then there is a jump to the next control not part of that radi^> button's group. In 
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instances when the next selectable control is off the bottom of the screen, the screen may 
be automatically scrolled to bring that control within view, followed by selection of that 

j 

control. Alternatively, the auto-jump feature may be disabled in such instances. 

Figures 6A through 6D show a series of screens that jiemonstrate how this 
navigational feature operates. Table 3 describes how a user completes the editing of a 
text box (for entering an appointment) in conjunction with figures 6A through 6D. The 
highlight automatically jumps to the next control, the Date jnput icon control. 

Table 3. Auto-Jump - Text Box Editing 



Action 


Result / Expla 


nation 


Start - Figure 6A. 

When entering a new appointment, the 
user first needs to highlight the 
Description field 601. 


Using the Up y 
and 221B (Figv 
each control in 
In this case, th< 
Description fie 


1 Down arrow keys 221A 
ire 2), the user can scroll to 
a screen and highlight it, 
i user has highlighted the 
Id 601 to provide text input. 


The user presses the Select key to put the 
Description into "Edit" mode, where the 
user now can type, and the arrow keys 
only apply to the Description field. 


Figure 6B. 
Now the Descr 
in it for text in] 
button changes 
to give the use: 
him to press it 


iption field 601 has a cursor 
:>ut. Also, the Select softkey 
> to a checkmark symbol 602 
r visual feedback to instruct 
to complete the editing. 


User Types. 

The user types in a description into the 
Description field 601. 


Figure 6C. 
Notice how th< 
activated whik 


j Description field is still 
j the user types input into it. 


Select Key Press. 

The user presses the Select key to end the 
editing of the Description field. 


Figure 6D. 
After ending tl 
Description fie 
revert to the 01 
screen (i.e. higl 
field and requi 
highlight the n 
highlight "jum] 
next control, in 
Icon 603. 


te edit session on the 
Id, the highlight does not 
iginal state of the first 
flighting the Description 
ring a Down- Arrow to 
ext control), but instead the 
:>s" automatically to the 
this case the Date Input 
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Figures 7 A through 7E show a second example of th^ auto-jump feature, in 
which a user selects a duration of two hours for an appointment with a radio button 
control to automatically skip the cursor (highlighting) to thi next control, the Alarm 

checkbox control Afterward, if the user selects the Alarm cjheckbox, the cursor jumps 

j 

to the Push Button. Table 4 describes the operations and effects shown in Figures 7 A 
through 7E. 

Table 4. Auto-Jump — Radio Button Editing 



Action 



Result / Explanation 



Start - Figure 7 A 

When entering a "Length" for a new 
appointment, the user is required to select 
one radio button. 



The "1/2 hour]' radio button is highlighted, 
but not selected. 



Down Key Press 

The user presses the down arrow key 221B 
one time to select the next Length option. 



Figure 7B. 

Now the "1/2 hour" radio button is 
unhighlighted, and the "1 hour" radio 
button is highlighted instead. 

In addition, th£ "1 hour" radio button is 
already selected. This is because this is the 
default radio tjutton for the group. 

Note: A variation that can be 
implemented i|s to skip selected radio 
buttons, since they cannot be re-selected. 
This may not be desirable, however, as the 
user may want to leave the length as 1 
hour, and if it $kips this radio button then 
the user has toj scroll down two more times 
to get to the n^xt control. If it is 
highlighted, then the user can re-select it 
just to take adyantage of the jump out of 
the fields. I 
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Down Key Press 

The user presses the down arrow key 221B 
one time to select the next Length option. 


Figure 7C 
Notice that no 
is no longer hi 
radio button h 

The screen scr 
user presses tl 
go to each nex 


w the "1 hour" radio button 
ghlighted, and the M 2 hours" 
> highlighted instead. 

oils up automatically as the 
te down-arrow key 221B to 
t control. 


Select Press 

The user presses the Select key to set the 
appointment to 2 hours. 


Figure 7D. 
Notice that the 
now selected. 

Also notice th< 
is never highli 
out of the groi 
straight to the 
here the user c 
"Ok" button, o 
shown next. 


2 "2 hour" radio button is 

it the M 3 hours" radio button 
ghted. The highlight jumps 
ip of radio buttons and 
"Alarm" checkbox. From 
:an either down-arrow to the 
r select the Alarm, which is 


Select Press 

The user presses the Select key to set the 
Alarm for the appointment. 


Figure 7E. 
Notice that th< 
checked, and t 
jumped to the 
(because it is t 
screen). 


i "Alarm" checkbox is now 
he cursor automatically 
"Ok" key for the next input 
le next control on the 



Thus, a key advantage of the auto-jump feature is saying the user an unnecessary 



keystroke for every field he edits in a form. These keystrokes can become tedious to the 
5 user for large forms. 

IV. Control Context Sensitive Menu 

Users of mobile devices often find it very difficult to lenter data when doing so 
requires input of mixed text, numbers, and/or symbols. U$ers sometimes cannot 
1 0 determine how to change the text input mode (or they do nj^t even know or surmise 
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that they should). It is expected that similar complications and usability issues will 
occur for other controls in the future as the controls becom^ more sophisticated. It is 
also expected that mobile phone keypads will remain fairly constrained in terms of 
navigational options in the future. What is needed is a gooji user interface metaphor for 
providing context sensitive accelerators and helpers while editing data presented in a 
user interface control such as a text edit box, pop-up menu,j table, etc. 

In certain mobile device browsers, the solution for changing the mode for text 

editing is to overtake (reassign) the second softkey and reqijiire the user to press the 

i 

softkey to switch modes. It has been found that this approach is difficult for users to 
discover and use. This is difficult for users, because in all other applications, the second 
softkey typically causes navigation to other screens, not changing the mode on the 
existing screen. Changing the meaning of this softkey only |for one type of screen causes 
users to be reluctant to use the softkey. This is especially true during text input when 
users may fear losing data already entered. 

Some mobile phones have a hidden key combinatiori to change the text input 
mode (if they support mode changes). This is usually done] for example, by pressing a 
key or pressing and holding a key. One such device allows ithe user to change mode by 
pressing the star ("*") key. This approach is not intuitive, however, and is not always an 
available option for other phones. Another mobile phone allows input mode changes 
by pressing and holding the number key the user is using t6 type with. This approach 
also is not easily discoverable, intuitive, or memorable. Otljer phones change text input 
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mode by putting all of the characters possible on each key. This requires the user to 
type many more keystrokes than if they could simply switch modes. For example, if the 

I 

user tries to type "Steve", he will have to press "PQRS" for tjie "S", then "TUVt" for the 
"t", "DEFde" for the "e", etc. 

i 

5 One complicated control is the smart text-input conttol, such as that provided by 

Tegic. Most implementations of smart text input require hflrd-coded keys for their extra 
= behavior, and have not found another way to present their Options to the user, 
y Complex controls on PCs do not have this problem, since most of the problem arises 
J from the small number of navigational and data input keys. PCs handle the text input 
¥ control easily with the rich input metaphor provided by a fikll-size keyboard and a 
2 mouse. Other complicated controls, such as Spin Controls, Tables and Pop-up menus, 
L| are easily and efficiently navigated with a mouse. There is ho need to optimize or 
* provide helper menus or functions for those controls in suclfi an environment. 

To deal with increasingly complex controls, such as tfext edit boxes, tables, pop- 
up menus, and spin controls on a limited navigational devicje (e.g., one without a direct 
pointing device), a navigational mechanism is described herein which provides control 
context sensitive pop-up menus whenever a complex contrcjl is activated for editing its 
data. It is assumed, for purposes of describing this feature, fhat the mobile device 
supports the following keys: Up Arrow, Down Arrow, Primary Softkey, Secondary 
Softkey, and Back/ Clear key. To allow for context sensitive browsers with this limited 
navigational keyset, a GUI is provided in which the navigatjonal functionality of the 
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arrow keys and softkeys is split between two states: navigating the controls while 
scrolling the screen, and editing a control. 
This feature operates as follows: 

1) Upon entering any screen, the up/ down arrow keys 22lK and 221B are used for 
5 scrolling and highlighting of controls only: 

a) The arrow keys cause scrolling whenever the uset has reached the top or 
E3 bottom of the screen and the screen must scroll to show mo[re data, whether it requires 
SfJ highlighting or not. 

ij b) The arrow keys cause highlighting whenever thetfe is a highlightable control 

1W such as a radio button, text edit box, or push button that is Risible or becomes visible to 
"5 the right or below the currently highlighted control. Thus, the controls all are 
I y highlighted first, then the screen scrolls. If when the screen! scrolls, a new control 
H becomes visible, the control is highlighted. 

2) When the user wants to operate a control, the user must ^>ress the Enter key or 
1 5 primary softkey. 

a) This act will put certain controls into edit mode, \yhere the user can change its 
value (such as editing text, selecting a pop-up menu item, ojr spinning a spin-control). If 
the control goes into edit mode, the primary softkey is used! to take it back out of Edit 
mode (i.e. complete the editing session), and the secondary softkey is used to represent 
20 a control context sensitive menu. 
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b) On other controls the primary softkey will simply execute the control's default 
action (such as going to a menu, link, or push-button's destination, or toggling a 
checkbox). 

i 

Thus, case 2a above is the solution to solving the need for a helper menu for 
5 operating on a complex control on a navigational control-restrained device. 

Figures 8A through 80 show an example of how the control context sensitive 

i 

i s menu feature operates, and particularly, how the second softkey can be used to 
y represent a context sensitive menu depending on whether a control is selected. Here, 
J adding an appointment in a calendar application is used as |an example. Table 5 
f describes the operations and effects shown in Figures 8A through 80. 
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Table 5. Control Context Sensitive Menu 



Action 



Result / Explanation" 



Start - Figure 8A. 

Begin in the "New Appointment" screen. 



The second softkey (on the bottom right of 
the screen) is labeled "Menu." It 
represents the application menu 
programmed py the developer to appear 
whenever the juser is not editing within a 
control. 



Softkey 2 Pressed. 

The user presses the key associated with 
the second softkey 801, usually located 
below the "Menu" label button on the 
right. 



Figure 8B. 

Notice the Application sensitive menu 802. 
This is prograinmed by the developer, and 
has application wide options, like "View 
Month," "Vievt Week," and "View Today." 
It also has optjons that applies specifically 
to this appoinjment the user is editing, 
such as "Save," "Discard," and "New 
Appointment,! ' which starts over with a 
new appointrrient. 

In addition, th^e second softkey 801 
changed to "Dismiss" when this pop-up 
menu appeared. This is because the 
"Dismiss Bar" £03 is selected. 

The icons 804 £t the top of the menu 802 
are selectable \o perform browser 
functions, sudji as moving back a screen, 
going to the h6me card, and exiting the 
browser to m^ke a phone call. 



Softkey 2 Pressed. 

The user presses the second softkey 801 
("Dismiss") to dismiss the menu without 
selecting any items. 



Figure 8C. 
The user is ba<tk to the first screen again, 
as the user ch6se not to select any of the 
menu options.! 

At this point, the user can scroll down to 
select other controls; select the first softkey 
to "Edit" the "Description," or reselect 
"Menu" to view or perform application 
menu options. 
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Softkey 1 Pressed. 

The user presses the first softkey (on the 
left) 805 to "Edit" the "Description" text. 


Figure 8D. 
The Descriptic 
mode with th< 
ready for text 
softkey 805 is 
reason for this 
must be taken 
selecting othei 

In addition, th 
says "ABC" to 
mode. Thissc 
"TextEdit" me 
user in the ent 
application mt 
until the user 
Edit mode. 


)n control 806 is now in Edit 
j cursor drawn to show it is 
input. Also, the "Edit" 
now a "Checkmark". The 
is to show that the control 
out of Edit mode to begin 
- controls again. 

e second softkey 801 now 
show it is in text input 
ftkey now represents a 
:nu, accessible to help the 
ry of text. The previous 
inu is no longer accessible 

rikp^ thp rontrnl nnt of Tpvt 


Typing Info 

The user types in the description of the 
meeting. 


Figure 8E. 
Nothing chan^ 
text is shown i 

The user now 
number, and h 
input mode to 


jes other than that the user's 
n the display. 

wants to enter a phone 
as to transition to number 
do this. 


Softkey 2 Pressed. 

The user presses the second softkey 801 to 
view the Text Edit Menu. 


Figure 8F. 
The menu 806 
softkey 801 is i 
menu related t 
user to accept 
return the text 
being edited. '. 
change from A 
mode or Symb 
offers help to t 
beginning or e 

The menu 806 
highlighted as 
common thing 


activated by the second 
aow a context sensitive 

0 text input. It allows the 
the text, cancel the input, or 
to its original state before 

t also allows the user to 
lphabetic mode to Number 

01 mode. Finally, the menu 
tie user to jump to the 

ad of the text. 

comes up with " Alpha " 
the mode is the most 
a user changes. 
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Down Pressed. 

The user presses the down arrow to 
highlight the "Numbers" menu item. 



Figure 8G. 

The user can i|ow switch into number 
entry mode, j 



Softkey 2 Pressed. 
The user presses the second softkey 801 to 
view accept input into the Text Edit menu. 



Figure 8H. I 

The second softkey label is now "1 2 3", 
which shows (he user that the device is in 
number modd. 



Numbers typed. 

The user types in the phone number. 



Figure 81 

The numbers Appear on the screen. If this 
is a phone, th4n using number mode is the 
fastest way to enter numbers. 



Softkey 1 Pressed. 

The user presses the first softkey 805 to 
exit Text Edit mode. 



Figure 8J. 

The input is accepted and the highlight 
jumps to the rjext control, which is the 
Date Picker cdntrol 809. 

In addition, the second softkey has 
reverted to representing the New 
Appointment Application menu again. 



Softkey 1 Pressed. 

The user presses the first softkey 805 to 
pick a date. 



Figure 8K 

The Date Picker is displayed. This is just 
another web site or application on the 
device. It has its own menu on the second 
softkey as welf . 



Softkey 2 Pressed. 

The user presses the second softkey 801 to 
view the Date Picker menu. 



Softkey 2 Pressed. 

The user presses the second softkey 801 to 
dismiss the Date Picker menu. 



Figure 8L. 

The displayed! menu 810 applies only to 
picking dates. \ The user can accept the 
currently selected date, cancel date 
picking mode and return to the last screen, 
reset the date f o the date it had on entry, 
or select todayj's date. 



Figure 8M. 
The user returi 
before viewing 



is to the mode he was in 
the Date Picker menu. 



Softkey 1 Pressed. 

The user presses the first softkey 805 to 
change the month using the Month Spin 
Control. 



Figure 8N. 

The control goes into edit mode, and the 
second softkey 801 is dynamically 
reassigned to Represent a context sensitive 
menu for Spin controls. 
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Softkey 2 Pressed. 

The user presses the second softkey 801 to 
view the Spin Control menu. 



Figure 80. ! 

The Spin control menu 811 has items that 
help in changing the spin control's value. 
Notice how special items like "This 
Month" or a njonth every quarter are 
listed for fastek access. 



Hence, the second softkey is overtaken (reassigned) When editing a control. The 
resulting control context sensitive menu can be implemented in a device that has no 
direct pointing device (e.g., in a two-arrow device), without requiring any dedicated 
keys for this function. The menu is easily discoverable by tike user through normal 
usage of the browser. A user will discover it either by accident or by noticing that the 

icon (and potentially the label) in the second softkey has changed. Further, this feature 

j 

is easily remembered. As soon as the user discovers the control menu, he will 
remember it and use it in the future when he needs it. In addition, this feature is not 
intimidating for users to try. The second softkey can be used as a menu in all 
applications, so the user will not expect it to take them to arjother screen. The user will 

j 

try the feature without worrying about losing data. Moreover, this feature provides 
unique and different visual feedback to the user. A different icon will be drawn in this 
menu depending on the data input mode. 



V. Two Arrow Key Table Navigation and Calendar Date Selection 

Tables of information are a very popular feature in software products, as they 
help the developer both to lay out the data for easy viewing as well as to make it easier 
for the user to view and input data. On a small mobile device, there is also a need for 
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tables, but the user wants to be able to navigate them with £s few keystrokes as 

possible. As noted above, many mobile devices only support up and down arrow keys, 

i 

and most also have a select key that can be used with the uj? and down arrows to select 

i 

an item. However, tables generally require four-directionaj. pointing control (i.e., left, 
right, up and down) for the most effective navigation. 

Certain mobile devices allow a user to navigate tables by requiring the user to 

i 

press the down arrow key once to advance to each cell in tfje table, moving through 
each cell in each row before going to the next row. The up £rrow key reverses the 
direction. Although this may be intuitive for the user, it is |ery tedious if the table is 
large. There is a need, therefore, for an efficient way to navigate a table on a mobile 
device with only two opposing arrow keys. 

Described herein is a feature for more efficient table havigation in a two-arrow 
mobile device. The user navigates a table by selecting rows! first, with each row 
highlighted as the user proceeds down the table (and reversing the direction with the 
up-arrow). After highlighting the row on which the user wjants to operate, the user uses 
the Select (or "Enter") key to select that row. After a row isiselected, the up and down 
arrow keys 221A and 221B, respectively, are used to navigate the cells in that row. Once 
the desired cell is highlighted, the user can use the Select ke^ again to select that cell. 
This approach enables the user to move more quickly when! pinpointing a cell of a large 
table. 
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Figures 9A through 9E show a series of screens for ak example that demonstrate 
how this table navigation feature works. Table 6 describes jthe operations and effects 

shown in Figures 9A through 9E. In this example, a calendar has been implemented as 

I 

a table of row and cells with dates. Calendars are a very popular feature to display to 
5 users on mobile devices when the user needs to select a date. A calendar is graphical 

and conveys more information to the user than a simple teit input box. First, the user 
i wi U highlight the row he wants, and then he will select thaij row to edit the cells. 



Table 6. Two Arrow Key Table Navi 



gation 



Action 


Result / Explanation 


Start - Figure 9A. 

The calendar is a table of rows and cells. 


On entry, the first row of the table is 
highlighted as this contains the current 
date. Other tafbles may come up with any 
logical row selected, or the first row 
selected if thai) makes the most sense, 
i 

The user can rjow highlight a different row 
by using the Up and Down arrow keys 
221A and 22li 


Down Key Press. 

The Down arrow key is pressed once to 
highlight the next row. 


Figure 9B. 
The next row i 
the calendar a] 
weekday cell ( 
tables the first 
become selecte 
user scrolls up 


s selected. In this example 
so pre-selected the first 
February 7 th ), but in other 
cell or any logical cell may 
d automatically when the 
or down. 
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Select Key Press. 

The Select key is pressed once to enter cell 
entry mode. 


Figure 9C. 

The last selected cell is highlighted, in this 
case Feb. 7 th . : 

Now the Up ^nd Down arrow keys move 
within the cells. 


Up Key Press. 

The Up arrow key is pressed once to 
highlight the previous cell. 


Figure 9D. 
The previous 


day, Feb. 6 th , is highlighted. 


Up Key Press. 

The Up arrow key is pressed once to 
highlight the previous cell. 


Figure 9E. 
Since there are 
the highlighte 
previous row 

When the usei 
press the Selec 
actions. 




> no more cells to the left of 
d cell, the last cell of the 
is selected, Feb. 5 th . 

- is done navigating, he can 
:t key to move on to other 



« Figures 10A through 10K show a series of screens fo^ another example of the 

U operation of the calendar (table) navigation, with smart selection of dates. Table 7 

7 describes the operations and effects shown in Figures 10A through 10K. The smart 

j 

selection comprises moving the cursor automatically to thejclosest weekday when the 
user is in row-selection mode (i.e. when the user is selecting a week) and navigates to a 
new week or month. It may be preferable to start on the cutrent day or the day the user 
is editing. 
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Table 7. Two Arrow Key Calendar Navigation with Smart Selection of Dates 



Action 



Result / Explanation 



Start - Figure 10A. 

When entering a new appointment, the 
user needs to enter a date. 



icon 



to 



The 'Date" 
can either go 
date, or he cah 
date. 



is highlighted. The user 
the next field and type in a 
use a calendar to select the 



Action Key Press. 

The Action Key is pressed to select "Pick" 
from the previous screen. 



Up Key Press. 
The Up arrow key is pressed once to 
highlight the previous week 



Figure 10B. 

On entry, the jifth week is highlighted as 
this contains the (example) current date. 
The currently [selected day has a box 
around it (the 26 th of January). 

The user can itow highlight a different 
week by usin^j; the Up and Down arrow 
keys 221A and 221B. 



Figure IOC. ! 

The last weekday is selected in the 4 th week 
of January. That is because in the selected 
week Friday t^ie 21 st is the closest weekday 
to January 26**]. 



Down Key Press. 

The Down arrow key is pressed once to re- 
highlight the current week. 



Figure 10D. 
The current 
selected again 
user to return 



dite 



is remembered and 
This makes it easy for the 
to the date they started with. 



Down Key Press. 

The Down arrow key is pressed once to 
highlight the next week. 



Figure 10E. 
The first weekday is selected in the sixth 
week of January. That is because Monday 
the 31 st is the closest weekday to January 
26 th , the previously selected date. 



Down Key Press. 

The Down arrow key is pressed once to 
highlight the next week. 



Figure 10F. 

The first weekday is selected in the first 
week of Feb. Jhat is because Monday the 
1 st is the closest weekday to Jan 26 th , the 
previously selected date. 



42 



Down Key Press. 

The Down arrow key is pressed once to 
highlight the next week. 


Figure 10G. 

The first weekday is selected in the second 
week of February. That is because 
Monday February 7 th is the closest 
weekday to January 26 th , the previously 
selected date. ; 


Select Key Press. 

The Select key is pressed once to enter day 
entry mode. 


Figure 10H. 

The last selected date is highlighted, in this 
case Februaryi 7 th . 

Now the Up ahd Down arrow keys move 
within the cells. 


Up Key Press. 

The Up arrow key is pressed once to 
highlight the previous day. 


Figure 101. 

The previous day, February 6 th is 

X i J ' J 

highlighted. : 


Up Key Press. 

The Up arrow key is pressed once to 
highlight the previous day. 


Figure 10J. 

Since there ar$ no more cells to the left of 
the highlighted date, the last day of the 
previous row js selected, Februay 5 th . 


Select Key Press. 

The Select key is pressed to accept the 
highlighted date. 


Figure 10K. 

The highlighted date from the last screen 
is inserted into the application. 



VI. Non-Scrolling Headers 

Wireless phone browsers currently support rendering a single page of markup 

language content using the full screen capabilities of the device. Often such pages will 

i 
j 

have a static title, but no support is provided for the popular and useful "frames" 

feature found on PC browsers. This shortcoming prevents ihe developer (content 

i 

provider) from providing and guaranteeing that certain important data is displayed on 
the screen while the user is accessing the developer's site, sijich as the developer's logo, 
an advertisement, or other features that are relevant to the page the user is on. 
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The problem is that frames are difficult to provide on a user interface that is 

i 

limited to up and down arrows and selection. If the device j has a direct pointing device 

such as a mouse, the user can easily switch frames using th^ pointing device, as done on 

i 

a PC. Without such a pointing device, however, it is very l^ard to determine where the 
5 user is focused on the device. 

This problem can be solved by allowing the developer to define a header or top- 

i 

! 

C3 level frame for the mobile device. This solution will also wprk for a footer frame and, 
1* given enough screen space, for side frames as well. The frajxie works by starting the 
y user's navigation on one of any highlightable controls within the header frame. The 

i: ; r. 

111 user can operate on these controls first, and then when the iiser scrolls down past the 

last control within the header frame, the first control in the body of the card is selected, 
rjj If the user scrolls past the visible area on the screen for the Ibody, then only the body 

H scrolls and the header remains fixed at the top of the screerv If the user scrolls up, then 

i 
i 

the content scrolls back down until there is no more contenj to scroll. At this point, the 
1 5 highlight jumps up to the header again, and works its way jhrough the header controls 
as the user presses the up or down arrow keys. 

Figures 11 A and 11B show a pair of screens for an example of how the non- 
scrollable header feature operates. Table 8 describes the operations and effects shown 
in Figures 11 A and 11B. In this example, the user enters anjelectronic mail ("Email") 
20 application and moves from the header to the body. ! 
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1 



Table 8. Non-Scrolling Headers 



Action 


Result / Expk 


mation 


Start — Figure 11A. 

Begin in the "Email" screen. 


The header 11 
labeled "Emai 
control that is 
"Inbox" pop-u 
highlighted. I 
header 1101 tc 
highlightable 
highlighted. I 
consists of the 
Items". Thebt 
the header 11 ( 
messages, witi 


01 (below the title bar 
1") has a highlight on the 
actionable in it, i.e., the 
p control 1102 is 
f there is nothing in the 
) highlight, then the first 
item in the body 1103 is 
n this example, the header 
"Inbox" menu and label "21 
)dy 1103 is the region below 
)1, as a list of email 
i the scrollbar on its right. 


Down pressed. 

The user presses the down arrow key to 
select the next item. 


Figure 11B. 
The first emai 
The user can r 
of the message 
down arrow, 
pressing the d 
he passes the ^ 
messages (or I 
screen) will sc 
up with the uj 
the way back 1 
the highlight \ 
actionable con 


. message is highlighted. 
low scroll down through all 
^s by repeatedly pressing the 
If the user scrolls down by 
own arrow repeatedly until 
viewable area, only the email 
)ody portion 1103 of the 
roll. When the user scrolls 
>-arrow, he must scroll all 
:o the first message before 
vill jump back up into an 
trol in the header 1101. 







Hence, this technique provides a way of implementing frames in a two-arrow 

mobile device, while also meeting good user interface desig|n criteria. This technique 

! 

5 does not require a dedicated key to switch between the heajier and the body or a direct 

i 

pointing device (e.g., a mouse). The technique is easily discoverable by the user 
through normal use of the browser. A user will arrive at screens with the highlighting 
positioned in the header, and will intuitively scroll down off of the header and into the 
body region. Once the user reaches the viewable body, he \jvill either expect the whole 
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the body scrolls quickly 



screen to scroll, or he will notice the scroll bar showing thai) the header will not scroll. 

! 

Either way, the user will quickly (and with feedback) discover that the header is not 

i 

scrolling. Upon returning to the top item in the body after Having scrolled down, the 
user will either intuitively know that he will continue scrolling through the body, or he 

5 may expect to jump to the header. Either way, the fact that 

indicates to the user that he must continue to press the up-^rrow until he has scrolled to 

3 the top of the body. [ 

n VII. Text Input Control 

1 Text input controls are form elements that can be us^d in a mobile device for 

; „ data input in the form of alphanumeric text entry. Text inpjat is one of the most 
^: complicated types of control. The complexity is increased due to the fact that users find 
3 it difficult to productively perform data input on a small mobile device and tend to 
avoid applications that require data input. In addition, usejs tend to accidentally delete 
text when doing so. This is due to the restrictive nature of the limited keyboards on the 

devices. For example, since "Clear" and "Back" functions ate often assigned to the 

i 

same key, users often make mistakes by misunderstanding jhe purpose of the keys and 
accidentally delete text when they want to go back, or go b^ck when they want to delete 
text. Even when these functions are on separate keys, there I may be problems, as on 
some devices the user presses the "Back" key intending to cjo a backspace, resulting in 
exiting the input screen and loss of the entered data. 
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To simplify text input for users, a text input control of the browser may include 
various features, including the following: 

• Growing Text Box: Text input is rendered as an inp^t area, which will display as 
much text as will fit into its area when it is rendered. The size of the text box will 
5 grow, as necessary, as the user enters data into it. T^xt input must occur within 

the defined area which the text edit control displays, 

3 • Auto-Fill: Automatic filling of old text entries typedj previously into a text input 
| control helps users by not requiring them to type th0 same input again. 

0 • Word Scroll: The user can move the cursor by characters or words automatically 
5t and efficiently. Specifically, if the user presses the Up or Down arrow keys, then 

3 the arrows will first navigate the highlighting by characters until the first space is 

3 reached, and then the highlighting will be jumped b^ words. This feature 

provides for easier word editing. 

Figures 12A through 12D illustrate the Growing Text Box feature. When a text 
5 input control is selected, the user must press the first softkejy 1201 which is an icon of a 

pen, to activate the text input control. After that, the user c^n type text (Figure 12C), 

I 

and if the user types more than the control can hold, then title text box 1202 will grow to 
accept more input, as shown by the difference between Figiires 12C and 12D, While 
activated, the primary softkey 1201 becomes a checkmark icjon to allow the user to end 
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the editing session, and the secondary softkey 1203 becomes assigned for activating a 
context sensitive pop-up menu, as described above. 

Figures 13A through 131 show a sequence of screens, illustrating an example of 
the operation of the Auto-Fill feature. This feature enables ithe recalling of information 
input into text input fields for later use. This feature can bd automatically turned on by 
default for all text input fields, and turned off by the developer should there be a 
sensitive field, such as for passwords or input fields that w^uld not likely yield a need 
for this feature. The Auto-Fill feature can also be automatically turned off for fields 
marked with the password input format. 

There are at least four possible ways to activate this feature: 

• The user activates a text input control that was already filled out in the past: 
When the user activates a text input control that has j?een filled out in the past, it 
will activate with the last typed input selected for th^ user. 

• The user selects "Old Entries" from a context sensitive pop-up (such as described 
above): This is a discoverable way for the user to select from other old input into 
the text input control. 

• The user presses the arrow keys after activating a cohtrol that has been filled in: 
If the user activates a control that has had input in the past, the last input is 
displayed immediately, and the user can use arrow %ys to find other input. 
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• The user starts typing input that matches old input: 'If the user starts to type in 
input that matches an old input, then the input field | will be filled in with the rest 
of the word selected. The user can stop typing and cjccept the entire word or 
phrase. 

Internally, the browser may cache old input according to a set of rules, such as 
the following, for example: 

• Cache up to 10 inputs for each field 

• Cache only the first 50 characters; and 

• Cache up to 20 fields, discarding by oldest fields by c^ate of last use. 
Regarding the first way of activating the Auto-Fill feature, consider the stock 

input example. Figures 13A through 13C show a sequence j^f displays for an example 
* of what happens if the user uses the same application a second time. In this example, 
merely activating the Symbol text input control causes the did input, "PHCM", to be 
automatically inserted into the text box 1301. In this case, assume that is what the user 
wanted, so the user presses the checkmark button (softkey) to accept the input and can 
now look up the value. 

For one embodiment, the user has the following choices upon activating a field 
and causing pre-filled input: ! 

• Accept the input (as above). 
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• Press "CLR" to clear the input, as shown in Figures }3D through 13G: This 
approach allows the user to type into a fresh empty held. 

• Type over input by typing any characters on keypad as shown in Figures 13H 
through 13K: This approach skips the "CLR" step frbm above. 

5 • Press the arrow keys to sequence through other old input, as shown in Figures 

13L through 130: Here the user could press the up/idown or left/right arrow 

3 keys immediately after entering a field to see other o^d input. In this example, 

the input is displayed from most recent input (e.g., Figure 13L) to oldest (e.g., 

h Figure 130) if the user presses the Down or Left arrow keys. If the user presses 

) the Right or Up arrow keys, then the next more recerkt input is shown, or the 

I: oldest input if the user is viewing the last input. ' 

1 A potential problem with the last example is that the! user must already know 

how the arrow keys work for this approach to work. This approach is not as easily 
discoverable as the other approaches, so there should be a n[iore discoverable way of 
finding old input as well. To compensate for this, an "Old Entries" feature can be 

added to a context sensitive pop-up (such as discussed abo\|e) when there are old 

i 

entries to be pasted, as shown in Figures 13P through 13U. ^election of the "Old 
Entries" entry 1302 (Figure 13R) brings up a pop-up menu, (ist, or dialog 1303 (Figure 
13S) over the text input field, with a list of previously used Input values for the field, 
which allows the user to select an old input value to be pasted into the field. The pop- 
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up 1303 works as any other conventional pop-up does, but disappears after a selection 
is made, leaving the input in the field 1301 (Figure 13U). If Ithe user scrolls off the pop- 
up 1303, he can dismiss it without making a selection. 

In case the user does not discover or understand the j"01d Entries" feature, there 

i 

can be a third shortcut for filling out fields as the user type^. If the user starts typing 

i 

something that matches an old input, the old input value is completed and selected as 
the user types, allowing the user to make a quick accept as ^vell 

VIII. Symbol Entry 

When inputting information into a wireless communications device, the user 
may wish to input one or more symbols, as opposed to text ior numbers. For example, 
the user might wish to input the "@" symbol to abbreviate the word "at" when 
recording the location of an appointment or when entering &n email address. 

Conventional wireless devices that have no direct input deMice can be difficult to 

i 

operate for purposes of symbol entry. Many wireless devices require a user to input 

i 

symbols by repeatedly pressing a particular key to scroll thrlough a list of symbols, 
which are displayed one at a time on the device's display, this process can be time- 
consuming and annoying to the user, particularly if there arb many symbols to scroll 
through. If the device allows scrolling through the symbols | in only one direction, as is 
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! 

often the case, the user may become frustrated if he inadveijtently passes the symbol he 

wanted, since he will then have to scroll through the entire list again. 

j 

Other wireless devices allow the user to enter a symbol entry mode by activating 

one of the softkeys. This action causes the entire display to jswitch into the symbol 
5 mode to display a page of selectable symbols. The user then activates another softkey 

to flip through pages of selectable symbols. A problem with this approach is that it is 
; not always intuitive for the user, such that the user may becjome confused about how to 
[j page through or select the symbols or how to exit the symbol entry mode. 
J Accordingly, a symbol entry mode of the browser may be designed to operate as 

9 follows. To facilitate description, assume that the device is in the text entry mode for 
« entering a new appointment, as shown in Figure 14A. First} the user presses the second 
y (right) softkey 1401 to activate the context sensitive pop-up menu. As shown in Figure 

14A, the first screen shows the second softkey 1401 being pijessed, but not released yet. 

The second softkey 1401 is then released by the user to causb the softkey menu 1402 to 

be displayed (Figure 14B). The user then scrolls down to sel 

(Figure 14C). The user presses the second softkey 1401 to select "Symbols" (Figure 14D) 

j 

in the context sensitive pop-up menu 1402 , causing activation of the Symbol mode, in 
which the Symbol Picker table 1403 appears (Figure 14E). 

The Symbol Picker table 1403 is displayed as a pop-u^) with a text edit control 
1404 already activated for typing in the symbol number. The symbol table shows all of 
the symbols that the user can choose from. The first softkey 1405 is labeled "Dismiss" 



Wt the "Symbols" item 
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to allow the user to dismiss the dialog without typing a symbol. Note that the second 
softkey 1401 is inactive. 

The user may scroll up and down in the Symbol Picker table to locate a desired 
symbol, as shown in Figure 14F. This is an optional action performed to show the 
5 content of the dialog; the user is not required to scroll dowA in order to make a 

selection. That is, a symbol need not be in view to be selected. 
% i To select a symbol, the user first types the number of the desired symbol (Figure 

f y 14G). As the user types, the first (left) softkey 1405 changesj from "Dismiss" to the 
W matching symbol. If the user continues to type, the symbol j on the first softkey 1405 will 
f& continue to change to match the symbol represented by theinumber the user types. The 
j* user then presses the first softkey 1405 to select the symbol (Figure 14H). When the user 
f y releases the first softkey 1405, the symbol is inserted at the Insertion point in the original 
r=s text input control 1406 (Figure 141). 

Hence, the above-described symbol entry feature provides a scrollable list of 
1 5 symbols, which displays multiple symbols simultaneously to avoid the need to 

repeatedly press a button to toggle between symbols. The feature does not consume the 
entire display, however, so that the user can more easily maintain context. 

DC Dual Feedback for Softkey Activated Controls 

20 As noted above, softkeys are labels displayed above physical (hardware) keys 

i 

that operate the function of the softkeys, in the manner described above. In early 
browsers, softkeys are simply labels with keys below them that perform the action 
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indicated by the softkey label on the screen. Typically, the action takes place with no 
user feedback, such that users do not always see the relationship between the physical 
key and the softkey label that specifies its operation. This l^ck of feedback often causes 
users to not understand what underlying behavior will occur when pushing the 
5 physical key. 

In more-recent graphical browsers with "real" buttons, such as push buttons, 
i icon buttons, and radio buttons, an opportunity presented ijtself to also make the 

y softkey buttons look more graphical or 3D-like. However, Users still may not recognize 

i i 

^ that the softkey label and the corresponding physical key a^e related. Also, with the 
f more-recent GUIs there is additional need for feedback to tlfie user to show the user that 
t he is properly operating on the correct control on the screeh- 

U Consider an example in which there are many radio buttons displayed. The user 

scrolls to select one radio button with physical arrow keys, but the user is unsure which 
physical keys should be pressed to activate the selected radio button. User feedback is 

5 required for both the physical key and the control being act^d on. Accordingly, the 
browser of the wireless device may provide improved feedback to the user when 
activating softkeys, as will now be described. 

Additional end-user feedback is added, in the form 6f making the softkey label 

! 

into a visual button that visually "depresses" on the displa^ as the corresponding 

physical key is pressed. In other words, the softkey label appears to be pressed down 

i 

when the user presses down the physical key, and that the ^oftkey label appears to be 
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released (impressed) when the physical key is released. Hence, the wireless device 
provides dual feedback- The user can use the arrow keys tQ select a control on the 
screen, such as a radio button, checkbox, or push button, ar(d then when the user 
presses the physical key, the softkey label and the control oji the display will both 

> depress simultaneously to help the user understand that th£ softkey is used to operate 
the control. 

i Thus, pressing the physical key causes a dual action:: When the user presses 

y down on the physical key, both the softkey label button depresses visually on the 
J display, and the control visually depresses on the display. When the user releases the 
f physical key, the softkey label returns to its original state at; the same time that the 
; control returns to its previous state. 

y Figures 15A through 15D show a series of screens foi" an example that 

demonstrates how this dual feedback technique operates, table 9 describes the 
operations and effects shown in Figures 15A through 15D. In this example, the user 

> traverses through radio buttons to select one to activate, an(i then the individual steps 
associated with pressing the physical key associated with the softkey that activates the 
radio button are shown. 
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Table 9. Dual Feedback for Softkey Activated Controls 



Action 



Results/ Comment 



Start - Figure 15A. 
Four radio buttons are 
displayed. 



The "1/2 hour" radio button has a border 
around it to show the user with visual 
feedback which radio biitton is currently 
selected. 

The first (left) softkey label 1501 has an 
icon that shows that the softkey will 
operate on the radio button if the user 
selects it. , 

It is very common for firbt-time users to 
discover that the up and down arrow 
keys on the device will r^iove the 
highlighted selection, but they often are 
confused about how to operate on the 
control they select once it is selected. 
New users rarely find it intuitive that the 
softkey is the control to J>ress to activate 
the radio button on earlier browsers that 
do not provide dual feedback. 



Figure 15B. 

The user presses the down 
arrow key on the wireless device 
to select the next radio button. 



The "1 hour" radio button is now 
selected. Scrolling with \he arrow keys 
only selects the radio button, but does not 
activate it. Notice how "£ hours" is the 
activated radio button. 
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Action 



Figure 15C. 

The user presses the physical 
key corresponding to the first 
softkey button label (e.g., button 
220 in Figure 2). Figure 15C 
shows the screen while the 
button is being pressed down, 
but not yet released. 



Figure 15D. 

The user releases the physical 
key associated with the left 
softkey. 



Results /Comment 



Both the radio button and the first softkey 
label 1501 are shown depressed. The first 
softkey label is indicates as being in the 
depressed "position" by its more- 
prominent border 1502 ip comparison to 
its appearance in Figure^ 15A and 15B. 
This dual visual feedback alerts the user 
to the softkey functionality so that the 
user is conditioned to look for its label to 
know what will happen] It also shows 
the control being activated on the screen 
(in this case the "1 hour'j radio button) in 
a depressed state, so the "user is clear he is 
performing the function he is attempting 
to perform. The "1 hour" radio button is 
indicated as being activated by its darker 
shading relative to its appearance in 
Figures 15A and 15B. 

Adding this dual feedback makes the 
interface easier to learn f or beginners. 
Users learn quickly how to associate 
softkey labels with the physical keys that 
activates them, as well as how controls 
work, such as the radio putton in this 
example. 



The "1 hour" radio button is now selected 
and both the radio button and the softkey 
label 1501 return to their previous 
(impressed) state. 



Thus, a method and apparatus for providing a microbrowser with a Graphical 
User Interface (GUI) in a hand-held wireless communication device have been 
described. Although the present invention has been described with reference to specific 

i 

! 

exemplary embodiments, it will be evident that various modifications and changes may 
be made to these embodiments without departing from the broader spirit and scope of 
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the invention as set forth in the claims. Accordingly, the specification and drawings are 
to be regarded in an illustrative sense rather than a restrictiVe sense. 
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